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INTRODUCTION 



The Operations Committee has asked me to evaluate a/PDP-jO 
group proposal concerning the way we deal with our softlmre — 
products. Presented with the opportunity to evaluate the 
proposal (prepared by Don Music and Bob Anundson) , I would like 
to broaden the scope and reconsider our entire approach to the 
development and marketing of software-related services. 

The concept of treating software like a product has many 
implications; like the more familiar hardware product, we must 
be prepared to discuss al]^ the costs, including development 
(engineering), distribution, installation, and warranty. We 
must consider the competitive nature of the product. We must 
define the quality and quantity of our support, and provide the 
mechanisms for maximizing profits through lower support costs. 
We should take advantage of the profit opportunities available 
when additional services are required; we should package the 
software product modularly so the customer can purchase only 
what he needs, and we must provide only what has been purchased. 
We should use our software and related services to enhance our 
competitive position; we should give our salesmen the flexibility 
to put together the most effective total package of hardware, 
software and support. 

From a mechanical standpoint, we must provide a uniform 
product identification scheme that will apply for all products 
across the company, and can be dealt with uniformly by order 
processing, the salesman, the customer, the Program Library, 
Software Support, and other involved organizations. 

In summary, we propose to treat software and software- 
related services as products, and establish the budgetary, 
financial and organizational basis for doing so effectively. 

A review of the broadened proposal is attached; it was 
prepared by Mel Woolsey, Hank Spencer, David Stone, Dave 
Schroeder and myself for your consideration. 



We propose to treat software and software-related services 
as products, and establish the budgetary, financial, and 
organizational basis for doing so effectively, in time to 
budget appropriately for FY '73. To do so, we must: 

1. Work with the Product Lines to establish prices 
for existing and planned software products. 

2. Budget software installation and warranty on the 
basis of number of units to be shipped and a 
defined support committment. 

3. Establish a uniform product identification system 
for all products. 

4. Create a viable software licensing posture as 
part of our standard terms and conditions. 

5. Establish a subscription service to allow the 
customers to buy a series of updates, newsletters, 
and other relevant information. 

6. Establish the accounting and administrative 
systems to track costs, control expenses, and 
register profits. 



What are the benefits? 

1. Recover development and support costs by charging 
for software and related services. 

2 . Improve our competitiveness in the iron Market by 
pricing and selling software products and services 
separately. 

3. Quantified support obligations allows minimized 
support cost, increased profit and better manage- 
ment of support costs. 

4. Limit costs of supplying free services and increase 
profit potential - limit use of software to those 
who help pay for it. 

5. Licensing of software products discourages the 
plug compatible market. 

6. Limit support expenses to those who paid for the 
license and are entitled to the support. 

7. Improve account servicing and responsiveness. 



8 Provide modularized expense concept - buy as much 
or as little as you need: software, hardware, 
services, systems. 

9. Uniform product naming unifies the DEC image. 

10. Ordering and order processing is simplified by 

naming of software products, services and systems. 

11 Software-related items can get into the standard 
waiver system to simplify distribution problems 
and control them better. 

12. Uniform corporate system allows uniform terminology 
and administration. 

13. Provide a financial measure of Programming Dept. 
performance. 

14. Encourage more competitive approach to software 
development. 

15. Encourage optimization of resource allocation to 

testing 
documentation 
support 
'^ customer training 

specialist training 

distribution 

etc. 

16. Single individual responsible to Product Line 
provides focus for negotiation and performance. 

17 . Simplify Product Line budgeting . 

18. Decrease administrative costs. 
Poieential Difficulties 

1. OEM sub-licensing of software may lead to paperwork 
hassle. 

2. Product naming which identifies market group may 
lead to multiple names for the same product, which 
would be confusing. 

3. Selling to plug-compatible OEMs would be more 
^^f^=^r^,1^+- because of price of software product. 



